Although the Internet Protocol (Internet Protocol, “IP” for short) has achieved huge success and made the Internet ubiquitous, “terminals” have been placed in a core position since the birth of IP, where a session carrying IP packets between two terminals is identified by using a destination IP address and a source IP address. Therefore, IP is a terminal centric network protocol. However, nowadays, a session between terminals is not the main purpose of using the Internet. Instead, people use the Internet mainly for acquiring information. For examples, applications such as network news, search engines, network music, network videos, blogs, microblogs, social networking sites, and network forums actually all focus on production, propagation, and sharing of information. Moreover, when acquiring the information, people usually do not care about where the information is acquired. This is a new information or content centric model. To solve the problem of mismatch between the information centric model of Internet applications and the terminal centric model of IP, the research circle starts trying to redefine the waist of an Internet hourglass model and studying a new future Internet architecture directly oriented to information and content.
Among all information centric network (Information Centric Network, “ICN” for short) architectures, a named data network (Named Data Network, “NDN” for short) has a greatest impact. The NDN is studied and developed from a content centric networking (Content Centric Networking, “CCN” for short) project led by Van Jacobson. The NDN and CCN consider that a future network should use content-based naming and routing as a basis, adopt URL-like structured content naming, implement a cache function by using a content store table (Content Store, “CS” for short) in an NDN router, and find and determine a next hop through longest matching between a content name of requested content and a content name prefix in a forwarding information base (Forwarding Information Base, “FIB” for short). The NDN is also dedicated to the implementation of content-name-based forwarding based on a current IP router and an Ethernet forwarding engine. Therefore, a routing table capacity problem is a major problem of interest in an NDN study. The NDN tries to solve this problem through name aggregation. However, because the size of a content name space is much larger than that of an IP address space, the NDN is faced with a rather serious routing scalability problem. Specifically, at present, the number of uniform resource locators (Uniform Resource Locator, “URL” for short) indexed by Google has exceeded 1012. Therefore, even if the FIB of the NDN stores only top-level domain names, there should be up to 2×108 routes according to the current network scale. If a part of second-level and third-level name prefixes are added, the size of a routing table is estimated to reach 6×108 routes. This number is almost two hundred times the number of Border Gateway Protocol (Border Gateway Protocol, “BGP” for short) routes in the current network, while the increase of BGP routes by 10 times takes nearly 10 years. Therefore, it can be hardly expected that current hardware such as a forwarding engine can support an NDN routing table of this size within a short term.
With respect to the preceding routing scalability problem of the NDN, a possible solution proposed by a content naming mechanism of the NDN is: adding a topology-dependent prefix before a content name, and then reducing the size of a routing table through topology aggregation. However, this naming mechanism obviously has a problem of naming non-persistence. In particular, as the mobile Internet is booming nowadays, it is expected that content naming should be location-independent from perspectives of mobility, multi-homing, services, and security. Another solution introduces a concept of routing label on the basis of a content name. A routing label is used to define the location of content, and a user or a routing node can acquire a routing label set corresponding to a content name by querying a name resolution system. However, in a process of forwarding a packet of interest, the content name is only used for cache lookup, and what really determines a forwarding route for the packet of interest is a routing label. Therefore, this technical solution weakens the concept of content routing. However, the routing label is a piece of location information in essence, and this technical solution has no essential difference from IP. Therefore, this technical solution is more like an IP router with an additional content cache function, rather than content routing in a real sense. In addition, the technology overemphasizes the function of a system for separating and mapping two name spaces, which causes the technology to be dependent upon the name resolution system, so that original flexibility of the NDN that is based on content routing is largely lost. Therefore, how to solve the routing scalability problem and the like that are caused by the content name, while ensuring flexibility of content routing, is a pressing issue to be solved in the study of current NDN systems and other ICN systems.